Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.224 < prev next >

Wrap

Text File | 1996-02-12 | 27.7 KB | 698 lines

Frequently Asked Questions (FAQS);faqs.224 Section 13. Lint 13.1: I just typed in this program, and it's acting strangely. Can you see anything wrong with it? A: Try running lint first (perhaps with the -a, -c, -h, -p and/or other options). Many C compilers are really only half- compilers, electing not to diagnose numerous source code difficulties which would not actively preclude code generation. 13.2: How can I shut off the "warning: possible pointer alignment problem" message lint gives me for each call to malloc? A: The problem is that traditional versions of lint do not know, and cannot be told, that malloc "returns a pointer to space suitably aligned for storage of any type of object." It is possible to provide a pseudoimplementation of malloc, using a #define inside of #ifdef lint, which effectively shuts this warning off, but a simpleminded #definition will also suppress meaningful messages about truly incorrect invocations. It may be easier simply to ignore the message, perhaps in an automated way with grep -v. 13.3: Where can I get an ANSI-compatible lint? A: A product called FlexeLint is available (in "shrouded source form," for compilation on 'most any system) from Gimpel Software 3207 Hogarth Lane Collegeville, PA 19426 USA (+1) 215 584 4261 The System V release 4 lint is ANSI-compatible, and is available separately (bundled with other C tools) from Unix Support Labs (a subsidiary of AT&T), or from System V resellers. Section 14. Style 14.1: Here's a neat trick: if(!strcmp(s1, s2)) Is this good style? A: Perhaps; perhaps not. The test succeeds if the two strings are equal, but its form suggests that it tests for inequality. Another solution is to use a macro: #define Streq(s1, s2) (strcmp((s1), (s2)) == 0) Opinions on code style, like those on religion, can be debated endlessly. Though good style is a worthy goal, and can usually be recognized, it cannot be codified. 14.2: What's the best style for code layout in C? A: K&R, while providing the example most often copied, also supply a good excuse for avoiding it: The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently. It is more important that the layout chosen be consistent (with itself, and with nearby or common code) than that it be "perfect." If your coding environment (i.e. local custom or company policy) does not suggest a style, and you don't feel like inventing your own, just copy K&R. (The tradeoffs between various indenting and brace placement options can be exhaustively and minutely examined, but don't warrant repetition here. See also the Indian Hill Style Guide.) The elusive quality of "good style" involves much more than mere code layout details; don't spend time on formatting to the exclusion of more substantive code quality issues. Reference: K&R Sec. 1.2 p. 10. 14.3: Where can I get the "Indian Hill Style Guide" and other coding standards? A: Various documents are available for anonymous ftp from: Site: File or directory: cs.washington.edu ~ftp/pub/cstyle.tar.Z (128.95.1.4) (the updated Indian Hill guide) cs.toronto.edu doc/programming giza.cis.ohio-state.edu pub/style-guide Section 15. Floating Point 15.1: My floating-point calculations are acting strangely and giving me different answers on different machines. A: First, make sure that you have #included <math.h>, and correctly declared other functions returning double. If the problem isn't that simple, recall that most digital computers use floating-point formats which provide a close but by no means exact simulation of real number arithmetic. Underflow, cumulative precision loss, and other anomalies are often troublesome. Don't assume that floating-point results will be exact, and especially don't assume that floating-point values can be compared for equality. (Don't throw haphazard "fuzz factors" in, either.) These problems are no worse for C than they are for any other computer language. Floating-point semantics are usually defined as "however the processor does them;" otherwise a compiler for a machine without the "right" model would have to do prohibitively expensive emulations. This article cannot begin to list the pitfalls associated with, and workarounds appropriate for, floating-point work. A good programming text should cover the basics. References: EoPS Sec. 6 pp. 115-8. 15.2: I'm trying to do some simple trig, and I am #including <math.h>, but I keep getting "undefined: _sin" compilation errors. A: Make sure you're linking against the correct math library. For instance, under Unix, you usually need to use the -lm option at the end of the command line when compiling/linking. 15.3: Why doesn't C have an exponentiation operator? A: You can #include <math.h> and use the pow() function, although explicit multiplication is often better for small positive integral exponents. References: ANSI Sec. 4.5.5.1 . 15.4: I'm having trouble with a Turbo C program which crashes and says something like "floating point formats not linked." A: Some compilers for small machines, including Turbo C (and Ritchie's original PDP-11 compiler), leave out floating point support if it looks like it will not be needed. In particular, the non-floating-point versions of printf and scanf save space by not including code to handle %e, %f, and %g. It happens that Turbo C's heuristics for determining whether the program uses floating point are insufficient, and the programmer must sometimes insert a dummy explicit floating-point call to force loading of floating-point support. Section 16. System Dependencies 16.1: How can I read a single character from the keyboard without waiting for a newline? A: Contrary to popular belief and many people's wishes, this is not a C-related question. (Nor are closely-related questions concerning the echo of keyboard input.) The delivery of characters from a "keyboard" to a C program is a function of the operating system in use, and has not been standardized by the C language. Some versions of curses have a cbreak() function which does what you want. Under UNIX, use ioctl to play with the terminal driver modes (CBREAK or RAW under "classic" versions; ICANON, c_cc[VMIN] and c_cc[VTIME] under System V or Posix systems). Under MS-DOS, use getch(). Under VMS, try the Screen Management (SMG$) routines. Under other operating systems, you're on your own. Beware that some operating systems make this sort of thing impossible, because character collection into input lines is done by peripheral processors not under direct control of the CPU running your program. Operating system specific questions are not appropriate for comp.lang.c . Many common questions are answered in frequently-asked questions postings in such groups as comp.unix.questions and comp.os.msdos.programmer . Note that the answers are often not unique even across different variants of a system; bear in mind when answering system-specific questions that the answer that applies to your system may not apply to everyone else's. References: PCS Sec. 10 pp. 128-9, Sec. 10.1 pp. 130-1. 16.2: How can I find out if there are characters available for reading (and if so, how many)? Alternatively, how can I do a read that will not block if there are no characters available? A: These, too, are entirely operating-system-specific. Some versions of curses have a nodelay() function. Depending on your system, you may also be able to use "nonblocking I/O", or a system call named "select", or the FIONREAD ioctl, or kbhit(), or rdchk(), or the O_NDELAY option to open() or fcntl(). 16.3: How can I clear the screen? How can I print things in inverse video? A: Such things depend on the terminal type (or display) you're using. You will have to use a library such as termcap or curses, or some system-specific routines, to perform these functions. 16.4: How do I read the mouse? A: Consult your system documentation, or ask on an appropriate system-specific newsgroup (but check its FAQ list first). Mouse handling is completely different under the X window system than it is under MS-DOS than it is on the Macintosh. 16.5: How can my program discover the complete pathname to the executable file from which it was invoked? A: argv[0] may contain all or part of the pathname, or it may contain nothing. You may be able to duplicate the command language interpreter's search path logic to locate the executable if the name in argv[0] is present but incomplete. However, there is no guaranteed or portable solution. 16.6: How can a process change an environment variable in its caller? A: In general, it cannot. Different operating systems implement name/value functionality similar to the Unix environment in different ways. Whether the "environment" can be usefully altered by a running program, and if so, how, is system- dependent. Under Unix, a process can modify its own environment (some systems provide setenv() and/or putenv() functions to do this), and the modified environment is usually passed on to any child processes, but it is _not_ propagated back to the parent process. 16.7: How can I find out the size of a file, prior to reading it in? A: If the "size of a file" is the number of characters you'll be able to read from it in C, it is in general impossible to determine this number in advance. Under Unix, the stat() function will give you an exact answer, and several other systems supply a Unix-like stat() which will give an approximate answer. You can fseek to the end and then use ftell, but this usage is nonportable (it gives you an accurate answer only under Unix, and a guaranteed, but potentially approximate answer only for ANSI C "binary" files). Are you sure you have to determine the file's size in advance? Since the most accurate way of determining the size of a file as a C program will see it is to open the file and read it, perhaps you can rearrange the code to learn the size as it reads. 16.8: How can a file be shortened in-place without completely clearing or rewriting it? A: BSD systems provide ftruncate(), several others supply chsize(), and a few may provide a (possibly undocumented) fcntl option F_FREESP. Under MS-DOS, you can sometimes use write(fd, "x", 0). However, there is no truly portable solution. 16.9: How can I implement a delay, or time a user's response, with sub-second resolution? A: Unfortunately, there is no portable way. V7 Unix, and derived systems, provided a fairly useful ftime() routine with resolution up to a millisecond, but it has disappeared from System V and Posix. 16.10: How can I read in an object file and jump to routines in it? A: You want a dynamic linker and/or loader. It is possible to malloc some space and read in object files, but you have to know an awful lot about object file formats, relocation, etc. Under BSD Unix, you could use system() and ld -A to do the linking for you. There is also a GNU package called "dld" which takes care of some or all of this. See also question 7.5. Section 17. Miscellaneous 17.1: What can I safely assume about the initial values of variables which are not explicitly initialized? If global variables start out as "zero," is that good enough for null pointers and floating-point zeroes? A: Variables with "static" duration (that is, those declared outside of functions, and those declared with the storage class static), are guaranteed initialized to zero, as if the programmer had typed "= 0". Therefore, such variables are initialized to the null pointer (of the correct type) if they are pointers, and to 0.0 if they are floating-point. Variables with "automatic" duration (i.e. local variables without the static storage class) start out containing garbage, unless they are explicitly initialized. Nothing useful can be predicted about the garbage. Dynamically-allocated memory obtained with malloc and realloc is also likely to contain garbage, and must be initialized by the calling program, as appropriate. Memory obtained with calloc contains all-bits-0, but this is not necessarily useful for pointer or floating-point values (see question 3.9, and section 1). 17.2: How can I write data files which can be read on other machines with different word size, byte order, or floating point formats? A: The best solution is to use text files (usually ASCII), written with fprintf and read with fscanf or the like. (Similar advice also applies to network protocols.) Be skeptical of arguments which imply that text files are too big, or that reading and writing them is too slow. Not only is their efficiency frequently acceptable in practice, but the advantages of being able to manipulate them with standard tools can be overwhelming. If you must use a binary format, you can improve portability, and perhaps take advantage of prewritten I/O libraries, by making use of standardized formats such as Sun's XDR (RFC 1014), OSI's ASN.1, CCITT's X.409, or ISO 8825 "Basic Encoding Rules." See also question 9.10. 17.3: How can I return several values from a function? A: Either pass pointers to locations which the function can fill in, or have the function return a structure containing the desired values. See also questions 2.12, 3.4, and 9.2. 17.4: If I have a char * variable pointing to the name of a function as a string, how can I call that function? A: The most straightforward thing to do is maintain a correspondence table of names and function pointers: int function1(), function2(); struct {char *name; int (*funcptr)(); } symtab[] = { "function1", function1, "function2", function2, }; Then, just search the table for the name, and call through the associated function pointer. 17.5: I seem to be missing the system header file <sgtty.h>. Can someone send me a copy? A: Standard headers exist in part so that definitions appropriate to your compiler, operating system, and processor can be supplied. You cannot just pick up a copy of someone else's header file and expect it to work, unless that person is using exactly the same environment. Ask your compiler vendor why the file was not provided (or to send a replacement copy). 17.6: How can I call FORTRAN (C++, BASIC, Pascal, Ada, LISP) functions from C? (And vice versa?) A: The answer is entirely dependent on the machine and the specific calling sequences of the various compilers in use, and may not be possible at all. Read your compiler documentation very carefully; sometimes there is a "mixed-language programming guide," although the techniques for passing arguments and ensuring correct run-time startup are often arcane. cfortran.h, a C header file, simplifies C/FORTRAN interfacing on many popular machines. It is available via anonymous ftp from zebra.desy.de (131.169.2.244). In C++, a "C" modifier in an external function declaration indicates that the function is to be called using C calling conventions. 17.7: Does anyone know of a program for converting Pascal or FORTRAN (or LISP, Ada, AWK, "Old" C, ...) to C? A: Several public-domain programs are available: p2c written by Dave Gillespie, and posted to comp.sources.unix in March, 1990 (Volume 21); also available by anonymous ftp from csvax.cs.caltech.edu, file pub/p2c-1.20.tar.Z . ptoc another comp.sources.unix contribution, this one written in Pascal (comp.sources.unix, Volume 10, also patches in Volume 13?). f2c jointly developed by people from Bell Labs, Bellcore, and Carnegie Mellon. To find about f2c, send the mail message "send index from f2c" to netlib@research.att.com or research!netlib. (It is also available via anonymous ftp on research.att.com, in directory dist/f2c.) This FAQ list's maintainer also has available a list of other commercial translation products, and some for more obscure languages. See also question 5.3. 17.8: Where can I get copies of all these public-domain programs? A: If you have access to Usenet, see the regular postings in the comp.sources.unix and comp.sources.misc newsgroups, which describe, in some detail, the archiving policies and how to retrieve copies. The usual approach is to use anonymous ftp and/or uucp from a central, public-spirited site, such as uunet (ftp.uu.net, 192.48.96.9). However, this article cannot track or list all of the available archive sites and how to access them. The comp.archives newsgroup contains numerous announcements of anonymous ftp availability of various items. The "archie" mailserver can tell you which anonymous ftp sites have which packages; send the mail message "help" to archie@quiche.cs.mcgill.ca for information. Finally, the newsgroup comp.sources.wanted is generally a more appropriate place to post queries for source availability, but check _its_ FAQ list, "How to find sources," before posting there. 17.9: When will the next International Obfuscated C Code Contest (IOCCC) be held? How can I get a copy of the current and previous winning entries? A: The contest typically runs from early March through mid-May. To obtain a current copy of the rules and other information, send e-mail with the Subject: line "send rules" to: {apple,pyramid,sun,uunet}!hoptoad!obfuscate or obfuscate@toad.com Contest winners are first announced at the Summer Usenix Conference in mid-June, and posted to the net in July. Previous winners are available on uunet (see question 17.8) under the directory ~/pub/ioccc. 17.10: Why don't C comments nest? Are they legal inside quoted strings? A: Nested comments would cause more harm than good, mostly because of the possibility of accidentally leaving comments unclosed by including the characters "/*" within them. For this reason, it is usually better to "comment out" large sections of code, which might contain comments, with #ifdef or #if 0 (but see question 5.7). The character sequences /* and */ are not special within double-quoted strings, and do not therefore introduce comments, because a program (particularly one which is generating C code as output) might want to print them. References: ANSI Appendix E p. 198, Rationale Sec. 3.1.9 p. 33. 17.11: How can I implement sets and/or arrays of bits? A: Use arrays of char or int, with a few macros to access the right bit at the right index (try using 8 for CHAR_BIT if you don't have <limits.h>): #include <limits.h> /* for CHAR_BIT */ #define BITMASK(bit) (1 << ((bit) % CHAR_BIT)) #define BITSLOT(bit) ((bit) / CHAR_BIT) #define BITSET(ary, bit) ((ary)[BITSLOT(bit)] |= BITMASK(bit)) #define BITTEST(ary, bit) ((ary)[BITSLOT(bit)] & BITMASK(bit)) 17.12: What is the most efficient way to count the number of bits which are set in a value? A: This and many other similar bit-twiddling problems can often be sped up and streamlined using lookup tables (but see the next question). 17.13: How can I make this code more efficient? A: Efficiency, though a favorite comp.lang.c topic, is not important nearly as often as people tend to think it is. Most of the code in most programs is not time-critical. When code is not time-critical, it is far more important that it be written clearly and portably than that it be written maximally efficiently. (Remember that computers are very, very fast, and that even "inefficient" code can run without apparent delay.) It is notoriously difficult to predict what the "hot spots" in a program will be. When efficiency is a concern, it is important to use profiling software to determine which parts of the program deserve attention. Often, actual computation time is swamped by peripheral tasks such as I/O and memory allocation, which can be sped up by using buffering and cacheing techniques. For the small fraction of code that is time-critical, it is vital to pick a good algorithm; it is less important to "microoptimize" the coding details. Many of the "efficient coding tricks" which are frequently suggested (e.g. substituting shift operators for multiplication by powers of two) are performed automatically by even simpleminded compilers. Heavyhanded "optimization" attempts can make code so bulky that performance is degraded. For more discussion of efficiency tradeoffs, as well as good advice on how to increase efficiency when it is important, see chapter 7 of Kernighan and Plauger's The Elements of Programming Style, and Jon Bentley's Writing Efficient Programs. 17.14: Are pointers really faster than arrays? How much do function calls slow things down? Is ++i faster than i = i + 1? A: Precise answers to these and many similar questions depend of course on the processor and compiler in use. If you simply must know, you'll have to time test programs carefully. (Often the differences are so slight that hundreds of thousands of iterations are required even to see them. Check the compiler's assembly language output, if available, to see if two purported alternatives aren't compiled identically.) It is "usually" faster to march through large arrays with pointers rather than array subscripts, but for some processors the reverse is true. Function calls, though obviously incrementally slower than in- line code, contribute so much to modularity and code clarity that there is rarely good reason to avoid them. Before rearranging expressions such as i = i + 1, remember that you are dealing with a C compiler, not a keystroke-programmable calculator. Any decent compiler will generate identical code for ++i, i += 1, and i = i + 1. The reasons for using ++i or i += 1 over i = i + 1 have to do with style, not efficiency. (See also question 4.4.) 17.15: This program crashes before it even runs! (When single-stepping with a debugger, it dies before the first statement in main.) A: You probably have one or more very large (kilobyte or more) local arrays. Many systems have fixed-size stacks, and those which perform dynamic stack allocation automatically (e.g. Unix) can be confused when the stack tries to grow by a huge chunk all at once. It is often better to declare large arrays with static duration (unless of course you need a fresh set with each recursive call). (See also question 9.4.) 17.16: What do "Segmentation violation" and "Bus error" mean? A: These generally mean that your program tried to access memory it shouldn't have, invariably as a result of improper pointer use, often involving malloc. 17.17: Does anyone have a C compiler test suite I can use? A: Plum Hall (1 Spruce Ave., Cardiff, NJ 08232, USA), among others, sells one. 17.18: Where can I get a YACC grammar for C? A: The definitive grammar is of course the one in the ANSI standard. Several copies are floating around; keep your eyes open. There is one on uunet (see question 17.8) in usenet/net.sources/ansi.c.grammar.Z (including a companion lexer). The FSF's GNU C compiler contains a grammar, as does the appendix to K&R II. References: ANSI Sec. A.2 . 17.19: How do you pronounce "char"? A: You can pronounce the C keyword "char" in at least three ways: like the English words "char," "care," or "car;" the choice is arbitrary. 17.20: What's a good book for learning C? A: Mitch Wright maintains an annotated bibliography of C and Unix books; it is available for anonymous ftp from ftp.rahul.net in directory pub/mitch/YABL. This FAQ list's editor maintains a collection of previous answers to this question, which is available upon request. 17.21: Where can I get extra copies of this list? What about back issues? A: For now, just pull it off the net; it is normally posted to comp.lang.c on the first of each month, with an Expiration: line which should keep it around all month. It can also be found in the newsgroup news.answers . Several sites archive news.answers postings and other FAQ lists, including this one; the archie server (see question 17.8) should help you find them. See the meta-FAQ list in news.answers for more information. This list is an evolving document, not just a collection of this month's interesting questions. Older copies are obsolete and don't contain much, except the occasional typo, that the current list doesn't. Bibliography ANSI American National Standard for Information Systems -- Programming Language -- C, ANSI X3.159-1989 (see question 5.2). JLB Jon Louis Bentley, Writing Efficient Programs, Prentice-Hall, 1982, ISBN 0-13-970244-X. H&S Samuel P. Harbison and Guy L. Steele, C: A Reference Manual, Second Edition, Prentice-Hall, 1987, ISBN 0-13-109802-0. (A third edition has recently been released.) PCS Mark R. Horton, Portable C Software, Prentice Hall, 1990, ISBN 0-13-868050-7. EoPS Brian W. Kernighan and P.J. Plauger, The Elements of Programming Style, Second Edition, McGraw-Hill, 1978, ISBN 0-07-034207-5. K&R I Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language, Prentice Hall, 1978, ISBN 0-13-110163-3. K&R II Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language, Second Edition, Prentice Hall, 1988, ISBN 0-13- 110362-8, 0-13-110370-9. Knuth Donald E. Knuth, The Art of Computer Programming, (3 vols.), Addison Wesley, 1981. CT&P Andrew Koenig, C Traps and Pitfalls, Addison-Wesley, 1989, ISBN 0-201-17928-8. P.J. Plauger, The Standard C Library, Prentice Hall, 1992, ISBN 0-13-131509-9. Harry Rabinowitz and Chaim Schaap, Portable C, Prentice-Hall, 1990, ISBN 0-13-685967-4. There is a more extensive bibliography in the revised Indian Hill style guide (see question 14.3). See also question 17.20. Acknowledgements Thanks to Jamshid Afshar, Sudheer Apte, Dan Bernstein, Stan Brown, Joe Buehler, Burkhard Burow, D'Arcy J.M. Cain, Raymond Chen, Christopher Calabrese, James Davies, Norm Diamond, Ray Dunn, Stephen M. Dunn, Bjorn Engsig, Dave Gillespie, Samuel Goldstein, Alasdair Grant, Ron Guilmette, Doug Gwyn, Tony Hansen, Joe Harrington, Guy Harris, Jos Horsmeier, Blair Houghton, Kirk Johnson, Peter Klausler, Andrew Koenig, Tom Koenig, John Lauro, Don Libes, Christopher Lott, Tim McDaniel, Evan Manning, Barry Margolin, Mark Moraes, Darren Morby, Richard A. O'Keefe, Hans Olsson, Francois Pinard, randall@virginia, Pat Rankin, Rich Salz, Chip Salzenberg, Paul Sand, Doug Schmidt, Patricia Shanahan, Peter da Silva, Joshua Simons, Henry Spencer, Erik Talvola, Clarke Thatcher, Chris Torek, Goran Uddeborg, Wietse Venema, Ed Vielmetti, Larry Virden, Freek Wiedijk, and Dave Wolverton, who have contributed, directly or indirectly, to this article. Special thanks to Karl Heuer, and particularly to Mark Brader, who (to borrow a line from Steve Johnson) have goaded me beyond my inclination, and occasionally beyond my endurance, in relentless pursuit of a better FAQ list. Steve Summit scs@adam.mit.edu scs%adam.mit.edu@mit.edu mit-eddie!adam.mit.edu!scs This article is Copyright 1988, 1990-1992 by Steve Summit. It may be freely redistributed so long as the author's name, and this notice, are retained. The C code in this article (vstrcat(), error(), etc.) is public domain and may be used without restriction. Xref: bloom-picayune.mit.edu rec.arts.disney:11446 news.answers:4726 Path: bloom-picayune.mit.edu!enterpoop.mit.edu!mojo.eng.umd.edu!darwin.sura.net!mlb.semi.harris.com!uflorida!purdue!haven.umd.edu!uunet!seismo!tanida From: tanida@forseti.css.gov (Tom Tanida) Newsgroups: rec.arts.disney,news.answers Subject: rec.arts.disney FAQ, part 1a Summary: FAQ for rec.arts.disney Keywords: FAQ, disney Message-ID: <51656@seismo.CSS.GOV> Date: 16 Dec 92 22:44:36 GMT Expires: 16 Dec 92 22:44:36 GMT Sender: usenet@seismo.CSS.GOV Reply-To: tanida@esosun.css.gov (Tom Tanida) Followup-To: rec.arts.disney Lines: 645 Approved: news-answers-request@MIT.Edu Nntp-Posting-Host: beno.css.gov Originator: tanida@beno.CSS.GOV Archive-name: disney-faq/part1a Last-modified: 16 Dec 1992 Frequently Asked Questions List For rec.arts.disney, part 1 Version 1.4, last revised 12/16/92